Managing routing information in a hub-and-spokes network

ABSTRACT

A routing device may be connected to multiple spoke site networks, and may receive local routes from these spoke site networks. The routing device may include routing information and forwarding information. The routing device may update the routing information to include the local routes, and selectively generate the forwarding information to exclude the local routes. The routing device may associate labels with the local routes and advertise the labels and local routes to other routing devices. The labels may be associated with interfaces of the routing device or access links that connect the routing device to a spoke site network, and the associations of labels with interfaces or access links may be stored in the forwarding information. The routing device may forward received packets that include the labels according to the labels, and may forward other received packets according to the routes within the forwarding information.

This application is a continuation of U.S. application Ser. No.10/374,030, filed Feb. 25, 2003, which claims the benefit of U.S.Provisional Application Ser. No. 60/404,347 filed Aug. 16, 2002. Theentire content of application Ser. Nos. 10/374,030 and 60/404,347 isincorporated herein by reference.

TECHNICAL FIELD

The invention relates to the routing of packets within a network, andmore particularly, to the management of routing information by routerswithin a hub-and-spokes network.

BACKGROUND

A private network may include a number of devices, such as computers,owned or administered by a single enterprise. These devices may begrouped into a number of site networks, which in turn may begeographically distributed over a wide area. Each site network mayinclude one or more local area networks (LANs).

Traditionally, in order to maintain the privacy of the communicationsbetween these site networks, interconnection of these site networks hasbeen accomplished using dedicated communication lines leased from aservice provider. With the advent of Virtual Private Network (VPN)technology, enterprises can now accomplish private connectivity betweensite networks over a public network, such as the Internet. Byeliminating the need for dedicated lines between the site networks, VPNsyield substantial cost savings as compared to traditional privatenetworks.

A VPN may be configured in a hub-and-spokes topology. In ahub-and-spokes network, one site network is the hub, while other sitenetworks are the spokes. This configuration passes all data through thecentral hub site network; isolating the spoke site networks, andallowing communication between devices within different spoke sitenetworks only through the hub site network. An enterprise may desire toconfigure a VPN used by the enterprise in this manner in order tomonitor or control communications between devices within different spokesite networks. For example, the hub site network may be the network atthe headquarters of the enterprise, while the spoke site networks aretypically networks at geographically distributed branch offices, salesoffices, manufacturing or distribution facilities, or the like, of theenterprise. The enterprise may desire to configure the VPN in ahub-and-spokes topology to monitor or control communications betweenthese distributed facilities or offices at the headquarters.

Generally, each site network of a VPN connects to the public network viaat least one router on the public network administered by a provider ofthe VPN service. In some situations, multiple site networks of a singleVPN may be connected to the public network via the same router. Theconnection of multiple site networks to the same router may make itdifficult to maintain the desired packet flow in a hub-and-spokes VPN.An existing solution to this problem is to configure routers to maintaina separate routing and forwarding information for each site networkconnected to that router. This existing solution may, however, cause anumber of problems. For example, as the number of site networksconnected to a single router increases, the demands of maintaining aseparate routing and forwarding information for each connected sitenetwork on the processing and memory resources of that router willincrease proportionally. This increased demand might ultimately affectthe performance of that router, decreasing the performance of the VPN asa whole in a way that is apparent to the enterprise.

SUMMARY

In general, the invention is directed to techniques that may be used byrouting devices, such as routers, to manage routing information within ahub-and-spokes network. According to the principles of the invention, arouter connected to multiple spoke site networks selectively generatesforwarding information to exclude “local routes.” As used herein, a“local route” refers to a route from a first spoke site network to asecond spoke site network that traverses only a single router to whichthe first and second spoke site networks are commonly connected.Selective generation of forwarding information may allow routers toforward packets such that proper packet flow within a hub-and-spokesnetwork may be achieved without the use of per-site routing andforwarding information and the consumption of router memory andprocessing recourses associated therewith.

In particular, a spoke router according to the principles of theinvention may include a single set of routing information and a singleset of forwarding information. A hub router according to the principlesof the invention may include two sets of routing information and twosets of forwarding information. A spoke router may receive local routesfrom connected spoke site networks and routes that traverse a hub sitenetwork from a hub router. The spoke router may update routinginformation to include both hub routes and local routes, but mayselectively generate forwarding information to exclude the local routes.The spoke router may forward packets received from connected spoke sitenetworks according to the routes within the forwarding information,i.e., the routes that traverse the hub site network.

The spoke router may use labels associated with access links thatconnect the spoke router to spoke site networks to forward packetsreceived from the hub router to the spoke site networks. The spokerouter may associate the labels with local routes received fromconnected spoke site networks based on the access link a particularroute was received on. The spoke router may advertise the label with theroute. The hub router may push the labels onto packets sent to the spokerouter. The label/access link associations may be stored as forwardinginformation.

A hub router, according to the principles of the invention, may maintaintwo routing instances, a hub routing instance and a spoke routinginstance. Each routing instance may be associated with a set of routinginformation, a set of forwarding information, and an access link. Thespoke routing instance may be used to receive routes from connectedspoke site networks. The spoke routing instance stores these routes inspoke routing information, and selectively generates spoke forwardinginformation to exclude these routes. The hub routing instance copies thelocal routes from spoke routing information to hub routing information,generates hub forwarding information to include these routes, andadvertises these routes to the hub site network, which in turnadvertises these routes that now traverse the hub site network to thespoke routing instance. The spoke routing instance uses the routesreceived from the hub site network to forward packets received fromconnected spoke site networks or spoke routers to the hub site network.The hub site network forwards the packets to the hub routing instance,which may in turn forward the packets to the proper connected spoke sitenetwork or spoke router.

In one embodiment, consistent with the principles of the invention, amethod comprises receiving routes that include one or more local routes,and selectively generating forwarding information to exclude the localroutes.

In another embodiment, a routing device comprises an interface, and acontrol unit to receive routes that include one or more local routes viathe interface, and selectively generate forwarding information toexclude the local routes.

Another embodiment is directed to a computer-readable medium containinginstructions. The instructions cause a programmable processor to receiveroutes that include one or more local routes, and selectively generateforwarding information to exclude the local routes.

Another embodiment is directed to a method comprising receiving routes,determining whether the routes are local routes, associating labels withthe local routes, and selectively generating forwarding information toexclude the local routes.

Another embodiment is directed to a routing device including aninterface and a control unit to receive routes via the interface,determine whether the routes are local routes, associate labels with thelocal routes, and selectively generate forwarding information to excludethe local routes.

Another embodiment is directed to a computer-readable medium containinginstructions. The instructions cause a programmable processor to receiveroutes, determine whether the routes are local routes, associate labelswith the local routes, and selectively generate forwarding informationto exclude the local routes.

Embodiments consistent with the principles of the invention may offer anumber of advantages. For example, routers which selectively generateforwarding information to exclude local routes according to theprinciples of the invention may be prevented from forwarding packets ina manner that is contrary to the proper packet flow for a hub-and-spokesnetwork. Furthermore, routers may associate labels with local routes,and forward packets to connected spoke site networks without the use oflocal routes. Additionally, routers may maintain all routes for thenetwork in a single set of routing information and a single set offorwarding information in the case of a spoke router and two sets ofrouting and forwarding information in the case of a hub router, whichmay conserve the memory and processing resources of such a router,improving the performance of the network from the perspective of anenterprise. Use of routers that require only a limited number of sets ofrouting information and forwarding information to achieve proper packetflow may reduce the administrative burden associated with adding orremoving sites on hub-and-spokes network.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating an example virtual privatenetwork (VPN) configured in a hub-and-spokes topology.

FIG. 2 is a block diagram illustrating an example flow of routinginformation within the VPN of FIG. 1 consistent with the principles ofthe invention.

FIG. 3 is a flow diagram illustrating an example method that may beemployed by a spoke router to manage routing information.

FIG. 4 is a block diagram illustrating another example VPN configured ina hub-and-spokes topology.

FIG. 5 is a block diagram illustrating an example flow of routinginformation within the VPN of FIG. 4.

FIG. 6 is a flow diagram illustrating an example method that may beemployed by a hub router to manage routing information.

DETAILED DESCRIPTION

FIG. 1 is a block diagram illustrating an example virtual privatenetwork (VPN) 2 configured in a hub-and-spokes topology. VPN 2 includesa hub site network 8 and spoke site networks 12A-12C (“spoke sitenetworks 12”) connected to a public network 4. Hub site network 8 andspoke site networks 12 may be the geographically distributed sites of anenterprise. Although VPN 2 may include any number of spoke site networks12, FIG. 1, for simplicity, shows only spoke site networks 12

Public network 4 may include one or more autonomous systems (not shown),and may be the Internet. Public network 4 may include a number ofdevices (not shown), such as routers and switches, used to route packetsfrom point to point across public network 4. The enterprise associatedwith VPN 2 may utilize public network 4 to route packets betweengeographically distributed site networks 8 and 12.

Each of hub site network 8 and spoke site networks 12 may include one ormore devices (not shown), such as personal computers, laptop computers,handheld computers, workstations, servers, routers, switches, printers,fax machines, or the like. Each of hub site network 8 and spoke sitenetworks 12 may include one or more Local Area Networks (LANs) (notshown).

As shown in FIG. 1, hub site network 8 may be connected to publicnetwork 4 via a hub router 6. As shown in FIG. 1, spoke site networks 12may be connected to public network 4 via spoke routers 10A-B (“spokerouters 10”). Hub site network 8 and spoke site networks 12 may beconsidered to be edge networks of public network 4. Hub router 6 andspoke routers 10A-B may be considered edge routers within public network4. Further, hub router 6 and spoke routers 10A-B may be administered bythe entity, e.g., the provider, that provides VPN services to theenterprise that includes hub site network 8 and spoke site networks 12.Although the provider may provide more than one VPN utilizing routers6,10, and many providers may provide VPN services utilizing publicnetwork 4, FIG. 1, for simplicity, shows only VPN 2.

As will be discussed in greater detail below, routers 6,10 mayselectively generate forwarding information to exclude local routes inorder to achieve proper packet flow for hub-and-spokes VPN without theuse of individual routing and forwarding information for each accesslink 11 or interface and the consumption of router and VPN resourcesassociated therewith. As used herein, a “local route” refers to a routefrom a first network of spoke site networks 12 to a second network ofspoke site networks 12 that traverses only a single router 6,10 to whichthe first and second network of spoke site networks 12 are commonlyconnected. Routers 6,10 may receive local routes to connected spoke sitenetworks 12 from gateway devices within the connected spoke sitenetworks 12, or a user may configure local routes via programminginterfaces provided by routers 6,10. Routers 6,10 will also receiveroutes to the connected spoke site networks 12 that traverse the hubsite network. Routers 6,10 that selectively generate forwardinginformation will forward packets received from spoke site networks 12 onroutes that traverse hub site network 8, i.e., according to the properpacket flow.

Each of hub site network 8 or spoke site networks 12 may, as shown inFIG. 1, connect to public network 4 via a single hub router 6 or one ofspoke routers 10, or may be connected to public network 4 via multiplehub routers 6 or spoke routers 10. As shown in FIG. 1, multiple spokesite networks 12A-B may be connected to a single spoke router 10A.Although, as will be discussed below, spoke site networks 12 may also beconnected to public network 4 via hub router 6, FIG. 1, for simplicity,shows only spoke site networks 12 connected to public network 4 viaspoke routers 10. Further, although any number of spoke site networks 12may be connected to either a spoke routers 10 A-B or hub router 8, FIG.1, for simplicity, shows only spoke site networks 12A-B connected topublic network 4 via spoke router 10A, and spoke site network 12Cconnected to public network 4 via spoke router 10B.

Hub site network 8 may be connected to hub router 6, and each of spokesite networks 12 may be connected to spoke site routers 10A-B, via oneor more access links 11. One or more access links 11 may connect hubrouter 6 and spoke routers 10 to one or more gateway devices (notshown), such as routers, within hub site network 8 and spoke sitenetworks 12. Access links 11 may be PPP links, ATM links, Ethernetlinks, Frame Relay link, GRE tunnels, or the like. Furthermore, routers6, 10A-B may connect to gateway devices and to public network 4 via oneor more physical or logical interfaces (not shown) of routers 6,10.Network interface cards of routers 6,10 may provide the physical orlogical interfaces. Each access link 11 may correspond to a physical orlogical interface of routers 6,10. As shown in FIG. 1, hub router 6 maybe connected to a gateway device within hub network 8 by two accesslinks 11, for reasons that will be discussed below.

In general, routers 6,10 are used to facilitate the routing of packetsbetween site networks 8,12 of VPN 2, i.e., packets sent from a firstdevice within one of site networks 8,12 to a second device withinanother of site networks 8,12. Each of routers 6,10 may include acontrol unit (not shown) that is responsible for causing router 6,10 toexecute the functions ascribed to routers 6,10 herein. The control unitsmay be microprocessors, or the like. The control units of routers 6, 10may execute application program code stored computer-readable memory,such as RAM, ROM, CD-ROM, magnetic disk or tape, EEPROM, or the like,available locally or via a network connection, that cause the routers6,10 to execute the functions ascribed to routers 6,10 herein.

Routers 6,10 may exchange routing information with connected gatewaydevices within connected site networks 8,12 and with others of routers6,10. Connected gateway devices may advertise routes for destinationdevices within connected site networks 8,12 to routers 6,10. The routesthat routers 6,10 receive from connected gateway devices may be referredto as local routes. Routers 6,10 may also receive local routesconfigured by a user via programming interfaces provided by the controlunits. Routers 6,10 may advertise these local routes to others ofrouters 6,10. Routers 6,10 may advertise routes received from others ofrouters 6,10 to connected gateway devices, which may in turn communicatethose routes to devices within the connected site networks 8,12.

Spoke routers 10 may advertise local routes for destination deviceswithin connected spoke site networks 12 to hub router 6. Hub router 6may advertise routes for the same destination devices that traverse hubsite network 8 to spoke routers 10. Spoke routers 10 may use the routesreceived from hub router 6 to route packets to the destination devicesinstead of the local routes received from connected gateway devices inorder to assure proper packet flow within hub-and-spokes VPN 2, as willbe described in greater detail below.

Routers 6, 10 may exchange routing information with connected gatewaydevices using routing protocols such as static routing, RoutingInformation Protocol (RIP), Open Shortest Path First (OSPF), ExternalBorder Gateway Protocol (EBGP), or the like. Routers 6, 10A-B mayexchange routing information among themselves using routing protocolsuch as internal border gateway protocol (IBGP), interior gatewayprotocol (IGP), or the like.

Devices within different network sites 8,12 may communicate with eachother using the Internet Protocol (IP). Each such device may have an IPaddress that identifies it to other such devices. Consequently, therouting information exchanged by routers 6,10 may include IP addresses.

For example, the local routes received by a router 6,10 from a connectedgateway device, or configured by a user, may be local IP routes todevices within the connected site network 8,12. Each local IP routereceived by the router 6,10 may include the IP address of thedestination device, and may indicate that the next hop for receivedpackets with that IP address is the connected gateway device, i.e., thatreceived packets with that IP address should be forwarded to theconnected gateway device. When routers 6,10 advertise these local routesto others of routers 6,10, the advertising router 6,10 may advertise theIP address and indicate that the advertising router 6,10 is a next hopfor packets with that IP address. When hub router 6 advertises routesfor destination devices within spoke site networks 12 that traverse hubsite 8 to spoke routers 10, as will be described below, hub router 6 mayadvertise the IP addresses of the destination devices and indicate thathub router 6 is the next hop for packets with those IP addresses.

Through this exchange of routing information, the devices within sitenetworks 8,12 receive the information necessary to send packets to eachother, i.e., the IP addresses of destination devices. Routers 6,10 usethe routes received to determine how to forward a received packet, i.e.,to which connected gateway device to send a packet received from publicnetwork 4, or to which other router 6, to send a packet received from aconnected gateway device over public network 4. More specifically,routers 6,10 may use the received routes to determine which logical orphysical interface of the router 6,10 to forward the packet on. Thecumulative forwarding decisions of the routers 6,10 between theoriginating device and the destination device determine, in part, theroute that a packet will take between the originating device and thedestination device. Thus, the manner in which packets are routed withinVPN 2 will depend on the manner in which routers 6,10 manage routinginformation, and make forwarding decisions based on the routinginformation.

Proper packet flow for a hub-and-spokes VPN, such as hub-and-spokes VPN2, requires that packets originating from a device within a first spokesite network 12 and destined for a device within a second spoke sitenetwork 12 are forwarded by routers 6,10 in such a way that theytraverse hub site network 8 before reaching the destination device. Thepackets must traverse hub site network 8 so that one or more deviceswithin the hub site network 8 can receive and process or analyze thepackets before they are delivered to the destination. These devices maymonitor or control communications between the various spoke sitenetworks for the enterprise.

For example, when spoke router 10A receives a packet destined for adevice within spoke site network 12B or spoke site network 12C from agateway device within spoke site network 12A via an access link 11,spoke router 10A must forward that packet such that it is routed acrosspublic network 4 to hub router 6. Spoke router 10A may not forward thepacket directly to a connected gateway device within spoke site network12B via an access link 11, or to spoke router 10B via public network 4.When hub router 6 receives the packet, it must forward the packet to agateway device within hub site network 8 via a first access link 11. Thegateway device within hub site network 8 may further transmit the packetto one or more devices within hub site network 8 that will process oranalyze the packet. After the devices within hub site network 8 havereceived the packet and processed or analyzed the packet as desired bythe enterprise, the gateway device within hub site network 8 may returnthe packet to hub router 6 via a second access link 11. Hub router maythen forward the packet across public network 4 to spoke router 10A or10B. Spoke router 10A or 10B may forward the packet to a gateway devicewithin spoke site 12B or 12C via access links 11, which may in turntransmit the packet to the destination device. Hub router 6 and spokerouters 10 may, as will be discussed in greater detail below, beconfigured to manage routing information such that the proper forwardingdecisions are made and proper packet flow for hub-and-spokes VPN 2 isachieved.

The packets that routers 6,10 send to and receive from connected gatewaydevices within site networks 8,12 may be IP packets that contain the IPaddress of the originating device and the destination. Routers 6,10 maysimply forward the IP packets received from connected gateway deviceswithin site networks 8,12 across public network 4. In some embodiments,in order to maintain privacy of communications between site networks8,12, routers 6,10 may forward the IP packets across public network 4using secure packet tunnels that terminate at routers 6,10. Exemplarytunneling protocols include Internet Protocol Security (IPSEC),Point-to-Point Tunneling Protocol (PPTP), and Layer Two TunnelingProtocol (L2TP). In addition, routers 6,10 may forward packets acrosspublic network 4 using Multiprotocol Label Switching (MPLS).

Routers 6,10 using MPLS may establish one or more Label Switched Paths(LSPs) that connect routers 6,10 to each other. LSPs are unidirectionalpaths across public network 4 between an originating router 6,10 and aterminating router 6,10. Thus, in hub-and-spokes VPN 2, there may be oneor more LSPs established to transmit packets from hub router 6 to eachof spoke routers 10, and from each of spoke routers 10 to hub router 6.These LSPs may include a number of routers within public network 4 inaddition to the originating and terminating routers 6,10. Routers 6,10may establish LSPs using Label Distribution Protocol (LDP) or ResourceReservation Protocol (RSVP).

When a terminating router 6,10 using MPLS LSPs to receive packets overpublic network 4 advertises an IP route for a device within a connectedsite network 8,12 to the other routers 6,10, the terminating router 6,10will also advertise a label associated with an LSP with the IP route.When an originating router 6,10 receives a packet with the IP addresscorresponding to the advertised IP route, the originating router 6,10may push the label advertised by the terminating router 6,10 onto the IPpacket and forward the packet on the LSP associated with that label. Theterminating router 6,10 may pop the label off the IP packet, and use thelabel, instead of the IP address, to forward the packet to a connectedgateway device within connected site networks 8,12.

For example, the hub router 6 and spoke router 10A may establish two ormore LSPs to transport packets from hub router 6 to spoke router 10A;one LSP associated with each access link 11 interface combinations thatconnects spoke router 10A to gateway devices of each connected spokesite 12A-B. Each LSP may have an associated label. When receiving routesfrom connected gateway devices via an access link 11, spoke router 10Amay associate the routes with the labels associated with the access link11 or interface over which a particular route is received. Whenadvertising the routes to hub router 6, spoke router 10A may advertisethe labels associated with the access links 11 or interface with theroute. Hub router 6 may use the IP address of a received packet destinedfor either spoke site 12A or 12B to determine which label to push ontothe packet, and which LSP to forward the packet on. Spoke router 10Awill use the label on the incoming packet from hub router 6 to determinewhich access link 11 or interface to forward the packet on.

Whether or not MPLS is used to forward packets across public network 4,routers 6,10 may use labels associated with access links 11 to allowforwarding of packets to destination devices within the connected sitenetworks 8,12 without using the IP addresses of the packets. In otherwords, routers 6, 10 may associate labels with access links 11 orinterfaces, associate the labels with routes received via those accesslinks 11 or interfaces, advertise the labels with the routes, push thelabels onto packets sent via public network 4, and use the labels onpackets received from public network 4 to determine which access link 11or interface to forward the packet on, without actually using LSPs toforward the packets across public network 4. Routers within publicnetwork 4 may route packets containing the label using IP routing or atunneling protocol, and ignore the label. Routers 6,10 receiving packetsvia public network 4 via IP routing or a tunneling protocol may look forthe label and use the label to forward packets to connected sitenetworks 8,12.

As mentioned above, routers 6,10 may selectively generate forwardinginformation to exclude local routes in order to achieve proper packetflow for hub-and-spokes VPN 2. Routers 6,10 that selectively generateforwarding information will forward packets received from spoke sitenetworks 12 on routes that traverse hub site network 8, i.e., accordingto the proper packet flow. Spoke routers 10 may use labels to forwardpackets that have traversed hub site network 8 to destinations withinconnected spoke site networks 12.

FIG. 2 is a block diagram illustrating an example flow of routinginformation within VPN 2. As shown in FIG. 2, routing informationgenerally flows from spoke site networks 12 to spoke routers 10, fromspoke routers 10 to hub router 6, from hub router 6 to hub site network8. In addition, routing information flows in return from hub sitenetwork 8 to hub router 6, from hub router 6 to spoke routers 10, andfrom spoke routers 10 to spoke site networks 12. Proper packet flowwithin hub-and-spokes VPN 2 is generally the reverse of this routinginformation flow. Configuring routers 6,10 to selectively generateforwarding information to exclude local routes may cause routers 6,10 toforward packets such that proper packet flow for hub-and-spokes VPN 2 isachieved, i.e., such that packets originating from a device within afirst spoke site network 12 and destined for a device within a secondspoke site network 12 traverse hub site network 8.

As shown in FIG. 2, hub router 6 includes hub routing information 14Aand spoke routing information 14B. Hub router 6 also includes hubforwarding information 16A and spoke forwarding information 16B. Spokerouter 10A includes routing information 14C and forwarding information16C. Spoke router 10B includes routing information 14D and forwardinginformation 16D. Routers 6,10 may store routing information 14 andforwarding information 16 in one or more of a variety of datastructures, such as a number of tables, link lists, radix trees,databases, flat files, or other data structures. Hub router 6 includestwo sets of routing information 14A-B and two sets of forwardinginformation 16A-B for reasons that will be discussed below.

Generally, routers 6,10 store all routes received from connected gatewaydevices, from a user, or from each other within routing information 14.When a router 6,10 receives a new route, the router 6,10 updates therouting information 14 to include that route. Routing information 14Awill generally, as will be described below, include routes todestination devices within spoke site networks 12 advertised to hubrouter 6 by spoke routers 10. Routing information 14B will generally, aswill be described below, include routes to destination devices withinhub site network 8, and routes to destination devices within spoke sitenetworks 12 that traverse hub site network 8. Routing information 14C-Dwill generally, as will be described in greater detail below, includelocal routes for destination devices within spoke site networks 12received by spoke routers 10 from connected gateway devices within spokesite networks 12, and routes to the same destination devices withinconnected spoke site networks 12 and routes to destination deviceswithin other spoke site networks 12 that traverse hub site network 8.

Forwarding information 16 is used by routers 6,10 to forward receivedpackets, i.e., to determine over which access link 11 or interface toforward a received packet. Routers 6,10 may generate forwardinginformation 16 based upon the routes stored within routing information14. The routing protocols employed by routers 6,10 may prefer theshortest or most efficient route to a destination. Thus, the routingprotocols employed by spoke router 10A may generally prefer to use localroutes to generate forwarding information 16C. However, if spoke router10A used local routes to forward packets to destination devices withinconnected spoke site networks 12A-B, spoke router 10A would, forexample, forward packets received from a device within spoke sitenetwork 12A to a device within spoke site network 12B directly withoutforwarding the packets to hub router 6.

Thus, if a spoke router with multiple connected spoke site networks suchas spoke router 10A with connected spoke site networks 12A-B, uses localroutes to forward data to the connected spoke site networks, properpacket flow for a hub-and-spokes VPN will not be achieved. As will bediscussed in greater detail below, spoke routers 10 may selectivelygenerate forwarding information 16C-D to exclude local routes. Spokerouters 10 may instead use labels to forward packets to destinationswithin connected spoke site networks 12 in order to facilitate properpacket flow within hub-and-spokes VPN 2.

As mentioned above, routers 6,10 manage routing information such thatproper packet flow for hub-and-spokes VPN 2 is achieved. As describedabove, proper packet flow within hub-and-spokes VPN 2 requires that allpackets traverse hub site 8. In particular, proper packet flow requiresthat spoke routers 10 are not able to send packets directly to eachother via public network 4, that hub router 6 is not able to sendpackets to spoke routers 10 without first sending the packets to hubsite 8, and that spoke router 10A is not able to send packets from oneof spoke site networks 12A-B to another of spoke site networks 12A-B.

One aspect of the management of routing information by routers 6,10 toachieve proper packet flow within VPN 2 is the use of border gatewayprotocol (BGP) community tags by routers 6,10 when exchanging routinginformation with each other. BGP community tags are included in the IBGPmessages used to advertise routes as attributes of the routes. BGPcommunity tags may be used to prevent spoke routers 10 from receivingroutes advertised by each other, which will prevent spoke routers 10from sending packets directly to each other.

Spoke routers 10 may be configured to have an import target “hub” and anexport target “spoke.” Conversely, hub router 6 may be configured tohave an import target “spoke” and an export target “hub.” The exporttargets for hub router 6 and spoke routers 10 indicate which tag isincluded by routers 6,10 when advertising routes. Thus, when hub router6 advertises routes, it includes the “hub” tag with the routes, and whenspoke routers 10 advertise routes, they include the “spoke” tag with theroutes. The import targets indicate which routes routers 6,10 willinclude in their routing information 14A, C-D based on the tag includedwith the routes. Thus, hub router 6 will only include routes from spokesites 10 advertised with the “spoke” tag in routing information 14A, andspoke routers 10 will only include routes from hub site 6 advertisedwith the “hub” tag in routing information 14C-D.

If, for example, spoke router 10A advertises a route to a destinationwithin spoke site network 12A or 12B and includes the “spoke” tag withthe route, spoke router 10B will not include the route in routinginformation 14D, and will instead discard the route. Thus, if spokerouter 10B receives a packet from spoke site network 12C destined for adevice within spoke site network 12A or 12B, spoke router 10B will nothave a direct route to spoke router 10A available to it in routinginformation 14D, and will be prevented from forwarding the packetdirectly to spoke router 10A via public network 4.

Instead, spoke router 10B may have received a route to the destinationwithin spoke site network 12A or 12B from hub router 6 that included the“hub” tag, and included that route within routing information 14D. Theroute received from hub router 6 will be a route that traverses hub site8 before reaching the destination device, i.e., a route for which hubrouter 6 is listed as a next hop on the path to the destination device.Spoke site 10B may use that route to forward the packets to hub router6, which may forward the packet to a connected gateway device within hubsite network 8 via a first access link 11, receive the packet back fromhub site network via a second access link 11, and forward the packet tospoke router 10A—achieving the proper packet flow in hub-and-spokes VPN2. Similarly, the use of BGP community tags will prevent spoke router10A from sending packets directly to spoke router 10B, as the onlyroutes to destinations within spoke site network 12C included withinrouting information 14C will be routes for which hub router 6 is listedas a next hop.

Another aspect of the management of routing information, in this case byhub router 6, to achieve proper packet flow within VPN 2 is the is theconfiguration of hub router 6 to include two routing instances, 18A and18B (“routing instances 18”) for VPN 2, wherein each of routinginstances 18 is associated with an access link 11 between hub router anda gateway device within hub site network 8. The two routing instances 18of hub router 6 may be referred to as “hub” routing instance 18A and“spoke” routing instance 18B. Hub instance 18A is associated with hubrouting information 14A, hub forwarding information 16A, and a firstaccess link 11 connecting hub router 6 to a gateway device within hubsite 8. Spoke instance 18B is associated with spoke routing information14B, spoke forwarding information 16B, and a second access link 11connecting hub router 6 to a gateway device within hub site 8. Theconfiguration of hub router 6 in this manner may prevent hub router 6from forwarding packets to spoke routers 10 without first forwarding thepackets to the connected gateway device within hub site network 8.

Hub routing instance 18A is configured to receive all routes todestination devices within spoke site networks 12 advertised to hubrouter 6 by spoke routers 10, and store those routes within hub routinginformation 14A. Spoke routers 10 may advertise the routes with thespoke tag, and hub routing instance 18A may be configured with an importtarget of spoke, as described above. The advertised routes will indicatethat the advertising spoke router 10 is the next hop for the route.

Hub routing instance 18A may further be configured to advertise thereceived routes to the connected gateway device within hub site network8 via the first access link 11. Hub routing instance 18A will advertisethe routes with an indication that hub routing instance 18A via thefirst access link 11 is the next hop for the route. The connectedgateway device within hub site network may then advertise the receivedroutes to spoke routing instance 18B of hub router 6 via the secondaccess link 11. The connected gateway device within hub site network 8will advertise the routes with an indication that the connected gatewaydevice is the next hop for the routes. The connected gateway devicewithin hub site network 8 may be configured to receive only routesadvertised by hub routing instance 18A via first access link 11, and toadvertise routes only to spoke routing instance 18B via the secondaccess link 11.

Spoke routing instance 18B of hub router 6 is configured to update spokerouting information 14B to include the routes received from theconnected gateway device of hub site network 8, and advertise all routesreceived from the connected gateway device of hub site network 8 tospoke routers 10. Thus, spoke routing instance 18B may be configuredwith an export target of spoke, as described above, and spoke routers 10will update routing information 14C-D to include the routes receivedfrom spoke routing instance with the spoke tag. Spoke routing instance18B will advertise the routes with an indication that spoke routinginstance 18B is the next hop for the routes.

As mentioned above, routing protocols may generally prefer to generateforwarding information 16 using the shortest or most efficient routeswithin routing information 14. If hub router 6, like spoke routers 10,was configured with a single routing instance for VPN 2 that included asingle set of routing information and a single set of forwardinginformation, the single set of routing information would include boththe routes to destination devices within spoke site networks 12 thattraversed hub site network 8 and the direct routes to the samedestination devices received from the advertising spoke routers 10. Hubrouter 6 would select the direct route to include in its singleforwarding information, and would forward packets addressed to thosedestinations directly to spoke routers 10 such that the packets wouldnot traverse hub site network 8. By contrast, when hub router 6, whichmaintains separate routing instances as described above, receivespackets via spoke routing instance from spoke routers 10, the onlyroutes available within routing information 14B are routes for which theconnected gateway device within spoke site network 8 is the next hop.

Packets forwarded by spoke routers 10 according to routes received fromthe spoke routing instance 18B of spoke router 6 will follow the seriesof next hops to spoke routing instance 18B of hub router 6, hub sitenetwork 8, hub routing instance 18A of hub router 6, and the destinationspoke router 10A-B. This is the desired packet flow for hub-and-spokesVPN 2.

Another aspect of the management of routing information in order toachieve the proper packet flow within VPN 2 is the selective generationof forwarding information 16A,C-D by routers 6,10, and the use of labelsby routers 6,10 to enable forwarding of packets to connected sitenetworks 8,12 without the use of local IP routes. The selectivegeneration of forwarding information 16A,C-D and use of labels arenecessitated where a single hub router 6 or spoke router 10 is connectedto multiple spoke site networks 12. In VPN 2, spoke router 10A isconnected to spoke site networks 12A-B.

As described above, routing information 14C will include local routes todestination devices within spoke site networks 12A-B received fromconnected gateway devices within spoke site networks 12A-B or a user,and routes to the destinations within spoke site networks 12A-B thattraverse hub site 8 received from hub router 6. Selective generation offorwarding information 16C is necessary because the routing protocolsemployed by spoke router 10A would generally prefer to use the localroutes to generate forwarding information 16C. If spoke router 10A usedlocal routes to forward packets to destination devices within connectedspoke site networks 12A-B, spoke router 10A would, for example, forwardpackets received from a device within spoke site network 12A to a devicewithin spoke site network 12B directly without forwarding the packets tohub router 6, leading to improper packet flow for a hub-and-spokes VPN2.

When spoke router 10A receives a route, spoke router 10A will determinewhether that route is a local route. Where a route is received via anaccess link 11, spoke router 10A may determine whether the route is alocal route by, for example, identifying the access link 11, interface,or routing protocol the route was received by. A user configuring aroute for spoke router 10A may identify the route as a local route.

Spoke router 10A may store the local route in routing information 14C,but will selectively generate forwarding information 16C to exclude thelocal route. Local routes may be tagged or otherwise identified as localwithin routing information 14A such that they are not included whenforwarding information 16A is generated. The local route will beadvertised to hub router 6, and spoke router 10A will receive a route tothe destination of the local route that traverses hub site network 8from hub router 6, as described above. Spoke router 10A may selectivelygenerate forwarding information 16C to include the hub routes, which maynot be tagged or otherwise identified as local routes. Thus, forexample, when spoke router 10A receives a packet from a device withinspoke site network 12A destined for a destination device within spokesite network 12B, the only forwarding option available to spoke router10A will be the route that traverses hub site network 8. This willprevent spoke router 10A from forwarding the packet directly to spokesite network 12B, and lead to proper packet flow for hub-and-spokes VPN2.

However, if spoke router 10A does not include local routes todestination devices within spoke site networks 12A-B within forwardinginformation 16C, spoke router 10A will need another method to determinewhich access link 11 to forward packets destined for destination deviceswithin hub site networks 12A-B received from hub router 6 via publicnetwork 4 on. Spoke router 10A may, as described above, assign a labelto each access link 11, and associate the label for an access link 11with all routes received via that access link 11. Spoke router 10A maystore the associations of labels with access links 11 in forwardinginformation 16C. Spoke router 10A may dynamically associate labels withaccess links 11, or a user may configure the associations of labels withaccess links. Further, spoke router 10A may advertise the labelassociated with a route with the route to hub router 6. When hub router6 receives a packet destined from a destination device within spoke sitenetworks 12A-B, hub router 6 may push the label onto the packet andforward the packet across public network 4 to spoke router 10A. Whenspoke router 10A receives the packet, spoke router 10A may pop the labeloff the packet, look the label up in forwarding information 16C todetermine the associated access link 11, and forward the packet on thataccess link 11. Thus, spoke router 10A using labels, is able to forwardpackets to the correct gateway device within spoke site networks 12A-Bwithout using the local routes received from the gateway devices.

Although selective generation of forwarding information 16 may only benecessary in VPN 2 for spoke router 10A that is connected to multiplespoke site networks 12A-B, it may be desirable to configure all spokerouters 10 of a VPN to selectively generate forwarding information 16for consistency of configuration and scalability of the VPN. Further,for consistency and scalability, it may be desirable to configure allrouters 6,10 to assign labels to access links 11, and use the labels toforward packets on those access links 11. Spoke routing instance of hubrouter 6, for example may advertise a label with all routes advertisedto spoke routers 10. The routes may have been received from a connectedgateway device within hub site network via the second access link 11,and the label may be associated with access link 11. In addition tospoke routers 10 selectively generating forwarding information 16, whenhub router 6 is connected to spoke site networks 12, hub router 6 mayalso be configured to selectively generate forwarding information 16B,as will be described below.

FIG. 3 is a flow diagram illustrating an example method that may beemployed by spoke routers 10 to manage routing information. When spokerouters 10 receive a route (20), spoke routers 10 may determine whetherthe route is a local route, a spoke route received from the other ofspoke routers 10, or a hub route received from hub router 6 (22). Thisdetermination may, as described above, be made based on the presence ofa hub or spoke BGP community tag in the case of hub routes and spokeroutes, or based on user identification or the access link 11,interface, or routing protocol by which the route is received in thecase of local routes. If the route is a spoke route, spoke routers 10may discard the route (24). If the route is a hub route, spoke routers10 may update routing information 14C-D to include the route andselectively generate forwarding information 16C-D to include the route(26). If the route is a local route, spoke routers 10 may associate alabel with route (28), update routing information 14C-D to include theroute, and selectively generate forwarding information 16C-D to excludethe local route (30), as described above. Spoke routers 10 may tag orotherwise identify local routes within routing information 14C-D, andselectively generate forwarding information 16C-D to exclude taggedroutes. Spoke routers 10 may also advertise the route and the associatedlabel with the spoke tag, thus advertising the route and associatedlabel to hub router 6 (32), as describe above.

FIG. 4 is a block diagram illustrating another example VPN 40 configuredin a hub-and-spokes topology. Like hub-and-spokes VPN 2 of FIG. 1,hub-and-spokes VPN 40 includes hub site network 8 and spoke sitenetworks 12 connected to public network 4. However, VPN 40 includesspoke site networks 12A-B connected to public network 4 via hub router 6and spoke site network 12C connected to public network 4 via spokerouter 10. Although VPN 40, like VPN 2, may include a number of spokerouters 10 with multiple attached spoke site networks 12, forsimplicity, VPN 40 is shown in FIG. 4 as including only a single spokerouter 10 with the single attached spoke site network 12C.

Like VPN 2 of FIG. 1, proper packet flow for hub-and-spokes VPN 40,requires that packets sent by a device within one of spoke site networks12 and destined for a device within another of spoke site networks 12traverse hub site network 8. Routers 6,10 may manage routing informationas described above to achieve proper packet flow within hub-and-spokesVPN 40. In particular, routers 6,10 may selectively generate forwardinginformation to exclude local routes in order to achieve proper packetflow for hub-and-spokes VPN without the use of individual routing andforwarding information for each access link 11 or interface and theconsumption of router and VPN resources associated therewith. Routers6,10 that selectively generate forwarding information will forwardpackets received from spoke site networks 12 on routes that traverse hubsite network 8, i.e., according to the proper packet flow. Additionalobstacles to proper packet flow within hub-and-spokes VPN 40 may bepresented by the connection of spoke site networks 12A-B to hub router6. Hub router 6 may be configured to manage routing information in orderto overcome those obstacles.

FIG. 5 is a block diagram illustrating an example flow of routinginformation within hub-and-spokes VPN 40. As shown in FIG. 5, spokerouter 10 includes routing information 14C and forwarding information16C. As shown in FIG. 5, hub router 6 includes hub routing information14A and spoke routing information 14B. Hub router 6 also includes spokerouting information 14B and spoke forwarding information 16B.

As described above with reference to FIG. 2, hub router 6 may beconfigured to include two routing instances, a hub routing instance 18Aand a spoke routing instance 18B (“routing instances 18”). Hub routinginstance 18A may be associated with hub routing information 14A, hubforwarding information 16A, and a first access link 11 connecting hubrouter 6 to a gateway device within hub site network 8. Spoke routinginstance 18B may be associated with spoke routing information 14B, spokeforwarding information 16B, and a second access link 11 connecting hubrouter 6 to the gateway device within hub site network 8. Spoke routinginstance 18B of hub router 6 may also be associated with access links 11that connect gateway devices within spoke site networks 12A-B to hubrouter 6. In general, hub router 6 is configured with two routinginstances 18 to assure that hub router 6 forwards packets received fromspoke site networks 12A-B and spoke router 10 using routes that traversehub site network 8, as described above.

Hub routing instance 18A receives routes advertised by spoke router 10,e.g., local routes received by spoke router 10 from a connected gatewaydevice within spoke site network 12C, and updates routing information14A to include those routes. Hub routing instance 18A generatesforwarding information 16A to include those routes, i.e., to indicatethat packets received from hub site network 8 addressed to thedestination device indicated in the routes are to be forwarded to spokerouter 10. Hub routing instance 18A may advertise these routes to theconnected gateway device within hub site network 8 with an indicationthat hub routing instance 18A is the next hop for the routes. As aresult, the connected gateway device within hub site network 8 mayadvertise these routes to spoke routing instance 18B via the secondaccess link 11 with an indication that the connected gateway devicewithin hub site network 8 is the next hop for each of the routes. Spokerouting instance 18B may update spoke routing information 14B to includethese routes, and may generate spoke forwarding information 16B toinclude the routes, i.e., to indicate that packets received from spokesite networks 12A-B addressed to the destination devices within spokesite network 12C indicated by the routes are to be forwarded to hub sitenetwork 8. Spoke routing instance 18B may advertise these routesreceived from the connected gateway device within hub site network 8 toconnected gateway devices within spoke site networks 12A-B with anindication that spoke routing instance 18B is the next hop on the routesvia the access links 11 associated with spoke routing instance 18B.

Thus, packets sent from a device within a spoke site network 12A or 12Band destined for a device within spoke site network 12C will beforwarded from a connected gateway device within the spoke site network12A or 12B to spoke routing instance 18B via the access links 11associated with spoke routing instance 18B. Spoke routing instance 18Bwill forward the packets to the connected gateway device within hub sitenetwork 8. The connected gateway device within hub site network 8 willforward the packets to hub routing instance 18A. Hub routing instance18A will then forward the packets to spoke router 10. Spoke router 10will then forward the packets to a connected gateway device within spokesite network 12C, which will forward the packets to the destinationdevice. Thus, proper packet flow within VPN 40 for routes from spokesite networks 12A-B connected to hub router 6 to spoke site network 12Cconnected to spoke router 10 is achieved.

Spoke routing instance 18B may receive routes to destinations withinspoke sites 12A-B advertised by connected gateway devices within spokesite networks 12A-B via the access links 11 associated with spokerouting instance 18B or configured by a user, and may update spokerouting information 14B to include these routes. These routes are localroutes for hub router 6 that indicate that the connected gateway deviceswithin spoke site networks 12A-B are the next hop for the route.

Because hub routing instance 18A is used to advertise routes fordestinations within spoke site networks 12 to hub site network 8 inorder to create routes that traverse hub site network 8 as describedabove, hub routing instance 18A may receive the local routes withinspoke routing information 14B. Hub routing instance 18A may beconfigured to copy the local routes within spoke routing information 14Bto hub routing information 14A. Hub routing instance 18A may generateforwarding information 16A to include these local routes and may use thelocal routes to forward packets received from hub site network 8 toconnected gateway devices within spoke site networks 12A-B. Hub routinginstance 18A may advertise these routes to the connected gateway devicewithin hub site network 8 with an indication that hub routing instance18A is the next hop for the routes. The connected gateway device withinhub site network 8 may advertise these routes to spoke routing instance18B via the second access link 11 with an indication that the connectedgateway device within hub site network 8 is the next hop on the route.Spoke routing instance 18B may update routing information 14B to includethese routes to destinations within spoke site networks 12A-B thattraverse the hub site network 8. Spoke routing instance 18B mayadvertise these routes received from the connected gateway device withinhub site network to connected gateway devices within spoke site networks12A-B and to spoke router 10 with an indication that spoke routinginstance 18B is the next hop on the routes.

Spoke routing information 14B will thus include the local routes todestinations within spoke site networks 12A-B received from connectedgateway devices within spoke site networks 12A-B, and routes to the samedestinations that traverse hub site network 8 received from theconnected gateway device within hub site network 8. Spoke routinginstance 18B may selectively generate forwarding information 16B toexclude the local routes. Spoke routing instance 18B receives packetsfrom spoke router 10 and connected spoke site networks 12A-B and makesthe initial decision as to how to forward the packet for hub router 6.If spoke routing instance 18B forwards the packets using the localroutes, packets received from router 10 or a connected spoke sitenetwork 12A-B will be forwarded to another of connected spoke sitenetworks 12A-B without having traversed the hub site network 8, leadingto improper packet flow for a hub-and-spokes VPN 2. Spoke routinginstance 18B may, as described above, identify local routes, and tag thelocal routes within spoke routing information 14B such that when spokeforwarding information 16B is generated, the local routes are notincluded.

FIG. 6 is a flow diagram illustrating an example method that may beemployed by hub router 6 to manage routing information. Hub router 6 mayreceive routes for destinations within spoke site networks 12A-B fromconnected spoke sites 12A-B, as described above (50). Spoke routinginstance 18B of hub router 6 may receive these local routes fromconnected gateway devices within hub site networks 12A-B via associatedaccess links 11, or as configured by a user via a programming interface.Spoke routing instance 18B may update spoke routing information 14B toinclude these local routes, and selectively generate spoke forwardinginformation 16B to exclude these routes (52). Spoke routing instance 18Bmay identify local routes based on the interface or access link by whichthe routes were received, or based on user input. Spoke routing instance18B may tag the local routes within spoke routing information 14B, andmay selectively generate spoke forwarding information 16B by generatingspoke forwarding information 16B to exclude tagged routes.

Hub router 6 may also update hub routing information 14A to includethese local routes and generate hub forwarding information 16A toinclude these local routes (54). Hub routing instance 18A of hub router6 may be configured to copy the local routes within spoke routinginformation 14B to hub routing information 14A. Hub router 6 via hubrouting instance 18A may also receive routes for destination deviceswithin non-connected spoke site networks 12 from spoke routers 10 (56).Hub routing instance 18A may update hub routing information 14A andgenerate forwarding information 14B to include the routes received fromspoke routers 10 (58). These routes may be advertised by spoke routers10 using the spoke tag, and the hub routing instance may have an importtarget of spoke, as described above.

Hub routing instance 18A of hub router 6 may advertise the receivedlocal routes and spoke routes to a connected gateway device within hubsite network 8 (60). Spoke routing instance 18B of hub router 6 mayreceive routes to the destinations within spoke site networks 12 thattraverse hub site network 8 from the connected gateway device within hubsite network 8 (62). Spoke routing instance 18B may update spoke routinginformation 14B to include these routes and selectively generateforwarding information 16B to include these non-local routes (64). Spokerouting instance 18B may advertise the routes received from hub sitenetwork 8 to connected gateway devices within spoke site networks 12A-Band spoke router 10 (66).

Various embodiments of the invention have been described. These andother embodiments are within the scope of the following claims.

1. A method of controlling routing of data within a hub-and-spokesvirtual private network (VPN) that comprises a hub and a plurality ofspokes, wherein each of the plurality of spokes comprises a respectiveone of a plurality of spoke provider edge (PE) routing devices, whereina first one of the plurality of spoke PE routing devices is connected toat least two different spoke customer site networks located within asame first one of the spokes, and wherein each of the at least twodifferent spoke customer site networks is connected to the first one ofthe plurality of spoke PE routing devices using a respective accesslink, the method comprising: receiving, with the first spoke PE routingdevice for the first spoke, routes to destinations within the at leasttwo customer site networks of the first spoke from a plurality ofcustomer edge (CE) routing devices; determining, with the first spoke PErouting device for the first spoke, that the routes are local routeswhen: (i) the routes are between the at least two different customersite networks of the first spoke, and (ii) only traverse the firstspoke; and selectively generating, with the first spoke PE routingdevice for the first spoke, forwarding information for thehub-and-spokes VPN to exclude the local routes.
 2. The method of claim1, wherein the selectively generating forwarding information to excludethe local routes comprises: tagging the local routes within routinginformation in the first spoke PE routing device for the first spoke;and generating the forwarding information to exclude the tagged routes.3. The method of claim 1, further comprising identifying the localroutes based on an interface from which each of the local routes wasreceived.
 4. The method of claim 1, further comprising updating, withthe first spoke PE routing device for the first spoke, routinginformation to include the local routes.
 5. The method of claim 1,further comprising forwarding packets from the first spoke PE routingdevice for the first spoke according to the routes within the forwardinginformation.
 6. The method of claim 5, wherein receiving routescomprises receiving, with the first spoke PE routing device for thefirst spoke, routes from a hub router of the hub, wherein the forwardinginformation generated with the first spoke PE routing device for thefirst spoke includes routes received from the hub router, and whereinforwarding packets from the first spoke PE routing device for the firstspoke comprises forwarding packets to the hub router based on the routesreceived from the hub router.
 7. The method of claim 5, whereinreceiving routes comprises receiving, with the first spoke PE routingdevice for the first spoke, routes from a hub site network within thehub, wherein the forwarding information generated with the first spokePE routing device for the first spoke includes routes received from thehub site network, and wherein forwarding packets from the first spoke PErouting device for the first spoke comprises forwarding packets to thehub site network based on the routes received from the hub site network.8. The method of claim 1, wherein receiving routes to destinationswithin the at least two different customer site networks from theplurality of CE routing devices comprises receiving the routes at thefirst spoke PE routing device for the first spoke via access links, themethod further comprising: associating a respective one of a pluralityof labels with each access link; for each of the local routes,associating, by the first spoke PE routing device for the first spoke,the local route with the label associated with that access link by whichthe local route was received; advertising local routes and the labelsassociated with the local routes from the first spoke PE routing devicefor the first spoke to the hub of the hub-and-spokes VPN; receivingpackets that include the advertised labels at the first spoke PE routingdevice for the first spoke from the hub; and selecting, with the firstspoke PE routing device for the first spoke, on which of the accesslinks to forward the packets based on the labels.
 9. The method of claim8, further comprising storing the associations between labels and accesslinks in a single forwarding information data structure of the firstspoke PE routing device for the first spoke for the hub-and-spokes VPNmaintained by the first spoke PE routing device for the first spoke. 10.The method of claim 8, wherein the labels are label switched labels, andwherein receiving packets comprising receiving packets via labelswitched paths.
 11. The method of claim 1, further comprisingmaintaining, with the first spoke PE routing device for the first spoke,a first and second routing instance, wherein the first routing instanceis associated with first routing information and first forwardinginformation and the second routing instance is associated with secondrouting information and second forwarding information, whereinreceiving, with the first spoke PE routing device for the first spoke,routes to destinations within the at least two customer site networks ofthe first spoke from the plurality of CE routing devices comprisesreceiving routes via the second routing instance, and whereinselectively generating the forwarding information for the hub-and-spokesVPN to exclude the local routes comprises selectively generating thesecond forwarding information.
 12. The method of claim 11, furthercomprising copying local routes from the second routing information tothe first routing information.
 13. The method of claim 1, whereinreceiving, with the first spoke PE routing device for the first spoke,routes to destinations within the at least two customer site networks ofthe first spoke from the plurality of CE routing devices comprisesreceiving routes to destinations within the at least two customer sitenetworks of the first spoke from the plurality of CE routing devices viaat least one of interfaces provided by a network interface card and aprogramming interface of the first spoke PE routing device for the firstspoke.
 14. The method of claim 1, wherein the determination that theroutes are local is based on at least one of access links, routingprotocols, or interfaces by which the routes were received.
 15. A spokeprovider edge (PE) routing device of a single one of a plurality ofspokes of a hub-and-spokes virtual private network (VPN), the spoke PErouting device connected to each of a plurality of spoke customer sitenetworks within the single spoke via a respective one of a plurality ofcustomer edge (CE) routing devices and a respective access link, thespoke PE routing device comprising: a plurality of interfaces; and acontrol unit configured to: receive routes to destinations within theplurality of spoke customer site networks from the plurality of CErouting devices via one or more of the interfaces, determine that theroutes are local routes when: (i) the routes are between the at leasttwo different customer site networks of the single spoke, and (ii) onlytraverse the single spoke, and selectively generate forwardinginformation for the hub-and-spokes VPN to exclude the local routes. 16.The spoke PE routing device of claim 15, wherein the control unitselectively generates the forwarding information to exclude the localroutes by tagging the local routes within routing information andgenerating the forwarding information to exclude tagged routes.
 17. Thespoke PE routing device of claim 15, wherein the control unit updatesrouting information to include the local routes.
 18. The spoke PErouting device of claim 15, wherein the control unit receives packetsvia the interfaces, selects interfaces according to the routes withinthe forwarding information, and forwards packets on the selectedinterfaces.
 19. The spoke PE routing device of claim 15, wherein theinterfaces are coupled to the CE routing devices by respective accesslinks, and wherein the control unit associates a respective one of aplurality of labels with each of the access links, for each of the localroutes, associates the local route with the label associated with theaccess link by which the local route was received, advertises the localroutes and the labels associated with the local routes to a hub routingdevice within a hub of the hub-and-spokes VPN, receives packets thatinclude the advertised labels from the hub routing device, and selectson which of the access links to forward the packets based on the labels.20. A non-transitory computer-readable storage medium comprisinginstructions that control routing of data within a hub-and-spokesvirtual private network (VPN) having a hub and a plurality of spokes,wherein the hub comprises a hub provider edge (PE) routing device andeach of the plurality of spokes comprises a respective one of aplurality of spoke PE routing devices, wherein one of the plurality ofspoke PE routing devices is connected to each of a plurality of spokecustomer site networks within a single one of the plurality of spokes bya respective one of a plurality of customer edge (CE) routing devicesusing a respective access link, wherein the instructions cause aprocessor of the spoke PE routing device to: maintain a singleforwarding information data structure for the hub-and-spokes VPN forroutes associated with the plurality of spoke customer site networkswithin the single one of the spokes; receive routes to destinationswithin the plurality of customer site networks from the plurality of CErouting devices; determine that the routes are local routes when: (i)the routes are between the at least two different customer site networksof the single one of the spokes, and (ii) only traverse the single oneof the spokes; and selectively generate forwarding information withinthe single forwarding information data structure for the hub-and-spokesVPN to exclude the local routes.